行動健康應用的例子：腦震盪門診追蹤

[GitHub] Behavioral Intervention through Mobile Devices: a framework and an example

這是去年跟朋友合作的計畫，目前 prototype 已經在驗證階段，所以可以來介紹一下。

過去曾經寫過「行為干預科技」（Behavioral Intervention Technology, BIT）的介紹，現今的行動應用和穿戴式設備有很多都是以「健康」為訴求，但是大多是以「記錄」和「媒合」為主，直接由醫護人員提供的比較少。

這個專案的由來，是一位神經外科醫師發現，腦震盪的門診病患有很多是年輕人，而他們都有智慧型手機，所以他想是不是能把傳統的衛教文宣移植成行動應用，進而把一大串靜態的「須知」轉換成「依據病患症狀而提供的客製化建議」。當然，醫師同時也可以主動得知病患在門診後的即時狀況，有助於後續病患回診時做更精確的診斷。

 GitHub上包含了行動端和主機端的原始碼，安裝和使用說明。程式開發是採用 full stack Javascript，行動端使用 Ionic framework，主機端則是 MEAN.js。本專案原始碼授權都是 MIT license，歡迎自由取用和修改；但是症狀判斷和提供建議的內容和邏輯，是屬於長庚大學行為科學研究所的智慧財產，要使用或修改需取得該單位的授權。

嚴格說來這個 prototype 設計的並不夠細緻，主機端的安全認證機制其實沒有做得很嚴謹。一方面系統開發實非本人專長，我也是邊做邊學；另一方面，這個系統主要是作為資訊收集的工具，真正的應用重點，在於後續如何用收集到的症狀資訊協助醫師診斷，以及設計一個理想的 BIT 應用開發流程，而這些才是行動健康應用的核心能力。


在開發的過程中，遇到一個個人覺得頗值得思考的問題：健康應用的「使用者」，究竟是「醫護人員」，是「病患」，還是其他人？這在「使用者中心」設計當道的今日，增加了一些討論的空間。

畢竟「健康」是個抽象的概念，每個人願意為了這個抽象概念承擔的「麻煩」都不盡相同。其實不難想像，大多數的人對於健康其實不是那麼積極，甚至希望以生活享受為主，「反正病了再吞顆仙丹治病就好」，然而這並非醫護人員想要的；而對健康積極的人，常常會自己累積許多健康知識，但是這些知識不見得與醫護人員的認知相同，個人無從判斷誰的知識比較「對」，但是這種認知差距，常常也會造成系統設計時的困難。

這次專案，委託開發的是醫護人員，他們希望病患可以鉅細靡遺的紀錄各種生活瑣事，甚至把日記寫在行動應用裡，這當然關係到後續資料分析的豐富性，但是卻不見得符合一般人使用行動應用的習慣。在這個專案裡，我們當然是以委託人的意見為主，但是如果要讓使用者真的如實的紀錄症狀，個人覺得在設計上還有一些可以思考的空間。

我相信在醫療這麼龐大的生態系裡，每個關係人都可能是「使用者」，而每個使用者想要的都不一樣，需要有比較強有力的整合者出面來主導類似系統的設計，才能有比較全面的思考。理想上，醫療保險的負責單位，是整個生態系統裡接觸範圍最廣的，而病人的健康和醫護人員的方便，都可以直接轉換成它的商業利益，因此應該是最適當的整合者。不過台灣有健保制度在，這個市場的發展也就相對有限了。

[摘譯] 我該從事哪種大數據工作？

[原文] Where Should I Work In Big Data? | Big Cloud Recruitment

[摘譯]
大數據相關的人力需求在很多產業都已經開始顯現。很都求職者都想投入相關產業，但是不知道該從事大數據的哪個環節，也徬徨於究竟該選擇新創公司，還是加入已有規模的大企業。下面幾個問題，可以協助思考如何縮小尋找的範圍，對大多數產業都適用：

產品

你的產品吸引人嗎？能改變世界嗎？在新創企業，產品就是一切，它必須好到能撐過12輪的融資。在成熟的大企業裡，產品通常都被驗證跟測試過，但相對的也比較沒有改變或修改的空間，而工作也大多在於拓展現有的市場；如果你想要有機會發揮更多創造力，那麼新創企業會是比較好的選擇。

領導

新創企業提供了更多個人成長的空間，但是作為後加入者，務必要確認領導團隊有足夠的能力把公司跟產品賣出去，並且持續的獲得融資，因為這決定了你未來的薪水。而在成熟的大公司，重點在於公司拓展的野心：如果公司追求在這個領域持續成長，那麼才有立功升遷的機會，否則追求安穩很可能也代表著成長的停滯。無論在哪種形態的公司，理想上你的主管在技術上都要比你有更深的知識，否則何來的成長可言？

團隊

對於已經經營有年的團隊，要事先打聽他們的企業文化應該不難：有的是階級紀律嚴明，有的可能更像新創企業，有的可能聚焦在公司成長，有的則是專攻利基市場。而企業的文化決定了什麼樣的人會在那裡工作，所以最好先確定那樣的環境是否適合你。新創企業則傾向於網羅比較多元化性格的人群，有人專們追求挑戰，也有人指想交差了事，所以團隊的相處經驗可能會更「有趣」一點。

流程

創造力和規矩行事通常是互相衝突的，所以如果你對「標準工作流程」很在意，那麼新創團隊可能不是你的好去處。相對的，成熟的企業會有比較多的經驗和固定流程。

風險

大數據是個全新的產業，不要期待現有企業的 CXO（執行長、營運長、行銷長....）會真的很清楚大數據到底是什麼，因此也有很多不懂裝懂的人也在搶食這塊餅。所以，在一家已經有現成客戶的公司工作，風險會低很多；但是相對的，新創企業會有相對較高的潛在回報。


顯而易見的，究竟該加入哪種企業，主要的差異在於「個人特質」，而非技術能力。


[譯按]
原作者是大數據招聘 Big Cloud 的創辦人，所以常常面對求職者詢問這類問題。

英文流行音樂裡的天氣

只能說，真的是什麼都可以拿來作文本分析。

[原文]
 'Here comes the sun': Does pop music have a 'rhythm of the rain?'

[研究論文]
 'Is there a rhythm of the rain? An analysis of weather in popular music' Brown, S., Aplin, K.L., Jenkins, K., Mander, S., Walsh, C. and Williams, P. (2015) Weather DOI: 10.1002/wea.2464

英國幾所大學的聯合研究（Southampton, Oxford, Manchester, Newcastle Reading），分析了750首與天氣有關的英文流行歌曲，其中有不少有趣的發現。

• 「太陽」（sun）和「雨」（rain）是最常出現的天氣，而「暴風雪」（blizzard）是最少見的。
• 音樂創作者常常用天氣來表達情緒，也因此一首歌裡通常包含不只一種天氣現象，而包含最多天氣現象的歌是 Cobb and Buie 的 Stormy。
• 在 750 首歌的 900 多位創作者中，最常在歌曲裡使用天氣的前三名分別是：Bob Dylan, John Lennon 和 Paul McCartney。（好像都是同時代的人）
• 與天氣有關的歌曲，有7% 入選 Rolling Stone 2011 年的「史上最棒的500首歌」，相當於佔據了10% 的名單。
• 對照詞曲創作的時間跟當時的天氣，研究發現與「壞天氣」有關的歌曲數量，在劇烈天氣較常發生的 1950-70 年，顯著的多於相對天氣較好的 1970-90年代。

最近在分析歷史氣象資料，來找找看是不是有完整的中文流行音樂歌詞資料庫，說不定也有好玩的東西在裡面。

Read more at: http://phys.org/news/2015-07-sun-music-rhythm.html#jCp

[摘譯]七種常見對大數據的「誤讀」

[原文] 7 Common Biases That Skew Big Data Results - InformationWeek

[摘譯]
「資料驅動的決策流程」（data-driven decision making）目前普遍被認為是個聰明的做法， 但是有時候太過依賴資料，一些「看似真的卻不見得」的情況，反而會導致蒙受損失或增加意外的風險。這些資料分析結果的誤讀，可能是來自於資料本身的偏差，也可能是收集或分析資料的人造成的偏差。

常見的七種偏誤有：

確認偏誤（Confirmation Bias）

確認偏誤是最常見的人類的認知偏誤。當我們有預設的立場，有意或無意的想要證實某種假設或意見時，最常發生這種偏誤：我們會因為「感覺對了」，而主動去忽略某些「不支持這個看法」的細節，甚至想盡辦法讓資料支持原本的假設。

選擇性偏誤（Selection Bias）

資料的選擇過程往往不是完全隨機的，因此分析結果可以被延伸推論的程度，往往受到「怎麼選擇資料」的影響。尤其在資料爆炸的今日，如何在大數據裡選擇適當的、有代表性的部份來分析，對於分析的結果有很大的影響。

離群值（Outliers）

資料當中難免會有一些超出一般範圍的極端值，如果沒有清理資料而只直接看平均的話，這些離群的極端值會影響平均數，進而導致誤判。離群值或異常值的判定與篩選，在大量自動收集的資料裡特別需要注意。

辛普森悖論（Simpson’s Paradox）

當資料包含了不同性質的群體時，有時候在個別群體裡非常明顯的趨勢或現象，在把所有群體合併之後反而看不到，甚至呈現相反的狀況。辛普森悖論在「大數據」的時代尤其容易發生，它基本上可以解釋我們平常看到的醫學研究結果之所以常常會互相矛盾，也可以解釋為什麼很多看似設計精妙的行銷手法到頭來卻全然沒有效果。

過適（Over Fitting and Under Fitting）

有時候我們為了能解釋所有收集到的資料，而使用了太過複雜的理論，導致連不必要的雜訊也都解釋進去了，反而失去了類推到其他情況的能力。而有時候恰好相反，我們使用了過於簡化的理論，試圖能解釋一切，但資料裡卻處處有例外。「過適」在使用高維度非線性統計模型時特別容易發生。

混淆變項（Confounding Variables）

有時候我們觀察到兩件事情A跟B之間的關聯性並不真切，因為背後其實是另外一個現象C同時造成了A和B，而這個C就是所謂的混淆變項。有時候資料是分別由不同組織收集然後合併在一起，分析的時候很容易被混淆變項所干擾。舉例來說，有家信用卡公司在三年內客戶的信用分數幾乎翻倍，而其他公司基本上沒有變化，但結果發現這家公司是由於三年內進行了大量的併購活動，才造成客戶信用分數的成長。

並非所有的事情都是常態分布（Non-normality:  The Bell Does Not Toll）

很多常用的統計工具（例如t-test），都假設資料是常態分布，但現實中的資料不見得都符合這個假設。遇到非常態分佈的資料，卻硬要套上鐘形曲線，分析的結果很可能導致錯誤的決策。


[譯按]
上述的七個現象，前兩個比較屬於人心智上常見的認知謬誤，而後五個比較屬於統計和實驗設計的專業，大概所有「資料密集」的專業領域都會遇到。在商業上，後面五項通常可以由專業團隊來把關，但是作為決策者就要自己特別注意前面兩項了。

現實中有時候「認知謬誤」也是不得不然。當老闆語重心長的告訴你：「資料分析出來的結果，應該是支持我的提案的，對不對？」明白人都知道，是該犯一下選擇性偏誤來造成確認偏誤的時候了。當然，作為資料科學家，有時候也要有說不的骨氣。